Object visibility control for ray tracing

ABSTRACT

A computer graphics method and apparatus allows designer control over the rendering of objects and scenes, in a rendering system using ray tracing for example. A modeling system is adapted to accept rules for controlling how certain objects affect the appearance of certain other objects. In a ray tracing implementation, rules are specified by ray type and can be specified as either “including” all but certain objects or “excluding” specific objects for any given object. A rendering system extracts these rules from a bytestream or other input including other graphics data and instructions, and populates lists for internal use by other components of the rendering system. A ray tracer in the rendering system is adapted to consult the list when performing ray tracing, so as to enforce the rendering control specified by the content creator when the objects and scene are rendered.

FIELD OF THE INVENTION

[0001] The present invention relates generally to computer graphics, andmore particularly, to a method and apparatus for controlling renderingof objects and scenes using ray tracing techniques, for example.

BACKGROUND OF THE INVENTION

[0002] Computer graphics systems are important components in manyapplications, such as CAD/CAM, computer animation and gaming,visualization systems, flight simulators, special effects, medicalimaging, architectural visualization, virtual reality, etc.

[0003] Computer graphics involves the design or modeling of objects andscenes to be displayed (typically 3-dimensional, but can be2-dimensional), which models and designs are translated into data andinstructions in computer-readable form. Computer graphics systems usethese data and instructions, perhaps under the further stimulus of auser input through a joystick for example, to render these objects andscenes on a display for human perception.

[0004] During rendering, ray tracing techniques can be used to determinewhich of the modeled objects and/or portions thereof are to be includedin a scene (perhaps from a perspective determined from a user input).Recursive ray tracing techniques can further determine how theappearance of some objects may be affected by the presence of otherobjects and light sources (e.g. shadows). Although typical computergraphics systems allow designers to specify how individual objects areto be displayed (e.g. lighting, special effects, textures, etc.), it maybe desirable to allow a designer to further specify whether and howcertain objects can affect the appearance of certain other objects. Forexample, a designer may wish to force one object not to be shadowed fromanother object, even though the other object may lie in a path betweenthe first object and a specified light source. This presents a problemthat has not been addressed by the prior art, including computergraphics systems employing a ray tracing rendering scheme.

SUMMARY OF THE INVENTION

[0005] The present invention relates to a computer graphics method andapparatus for controlling the rendering of objects and scenes, in arendering system using ray tracing for example. A modeling system isadapted to accept rules for controlling how certain objects and/or lightsources affect the appearance of certain other objects and/or lights. Ina ray tracing implementation, rules are specified by ray type and can bespecified as either “including” all but certain objects and/or lights or“excluding” specific objects and/or lights. A rendering system extractsthese rules from a bytestream including other graphics data andinstructions and populates lists for internal use by other components ofthe rendering system. A ray tracer in the rendering system is adapted toconsult the list when performing ray tracing, so as to enforce therendering control specified by the content creator when the objects andscene are rendered.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] These and other aspects and features of the present inventionwill become apparent to those ordinarily skilled in the art upon reviewof the following description of specific embodiments of the invention inconjunction with the accompanying figures, wherein:

[0007]FIG. 1 is a top-level diagram illustrating an example computergraphics environment for an implementation of the present invention;

[0008]FIG. 2 is a functional block diagram illustrating an exampleimplementation of a rendering system in accordance with the presentinvention;

[0009]FIGS. 3A to 3C illustrate ray tracing processing of a scene withobjects that demonstrates certain aspects of the present invention;

[0010]FIG. 4 is an example of data structures that can be used toimplement the rules for controlling rendering in accordance with anaspect of the present invention; and

[0011]FIG. 5 is a flowchart illustrating an example method implementedin accordance with the principles of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The present invention will now be described in detail withreference to the drawings, which are provided as illustrative examplesof the invention so as to enable those skilled in the art to practicethe invention. Notably, the figures and examples below are not meant tolimit the scope of the present invention. Moreover, where certainelements of the present invention can be partially or fully implementedusing known components, only those portions of such known componentsthat are necessary for an understanding of the present invention will bedescribed, and detailed descriptions of other portions of such knowncomponents will be omitted so as not to obscure the invention. Further,the present invention encompasses present and future known equivalentsto the known components referred to herein by way of illustration.

[0013] A top-level block diagram of an example implementation of thepresent invention is illustrated in FIG. 1.

[0014] As shown in FIG. 1, a computer graphics system includes amodeling system 102 and rendering system 104. Although shown separatelyfor clarity, modeling system 102 and rendering system 104 can beimplemented as software that is commonly executed by a common processor.Alternatively, modeling system 102 and rendering system 102 areimplemented as hardware or software components that are separatelyprovided in different platforms and communicate with each other via abus, a network, or other communication means, using interprocess schemessuch as client-server communications, for example. It should be apparentthat many alternative topologies and implementations are possible.

[0015] Generally, modeling system 102 (e.g. Maya from Alias|Wavefront ofToronto, Ontario, Softimage|3D from Avid Technology, Inc. of Tewskbury,Mass. and 3D Studio Max from Discreet Logic, Inc. of Montreal, Quebec)allows a content creator/editor to model objects and specify how theyare to be displayed in a scene (e.g. lighting, effects, materialdefinitions) via GUI system 106. These models and instructions are sentby modeling system 102 to rendering system 104 to be displayed on adisplay 108 (which may be commonly or separately provided with GUI 106system such as in a SGI Octane visual workstation, for example) orcaptured in an image file. In one example, particularly where autonomybetween the modeling system 102 and rendering system 104 is desired,this transfer of graphics data and instructions is performed using anindustry standard interface such as the RenderMan Interface (see, forexample, the RenderMan Interface V3.1 description at www.pixar.com), ornon-standard interfaces based thereon. In accordance with an aspect ofthe invention, modeling system 102 allows a content creator/editor tofurther specify relationships between modeled objects and/or rulesconcerning how they are allowed to affect each other's appearance, andrendering system 104 is adapted to consider these relationships andrules and to render scenes in accordance therewith.

[0016] The present invention contemplates the use or adaptation ofvarious modeling systems and ways of specifying object relationships andrendering rules, and such are considered to be incidental to theinvention. In one possible implementation, modeling system 102 can bebased on the Maya modeling/animation system from Alias|Wavefront. Inthis example, as is known in the art, the Maya system includes anApplication Programming Interface (API) which is an open architecturethat includes the ability to provide additional graphics capabilitythrough plug-in applications. Accordingly, the present invention can beimplemented by providing a plug-in application(s) 103 to the Maya APIthat allows content creators to specify object relationships and rulesin addition to performing other modeling functions that are provided byMaya alone. Those skilled in the art will recognize various alternativeimplementations, whether or not including an environment such as Maya.Further, those skilled in the art will understand how to add thegraphics capabilities of the present invention by adapting or creatingother API's, plug-in applications 103 and the like after being taughtabout their functionality below.

[0017]FIG. 2 illustrates an example implementation of rendering system104. As shown in FIG. 2, a rendering system 104 includes a scene server202, a ray server 203, a ray tracer 204 and a shader 206. Scene server202 receives a graphics input (e.g. a RenderMan Interface Bytestream(RIB)), and in response provides scene parameters to ray server 203 andestablishes graphics data structures 208 (e.g. object descriptions,textures, surface shading programs, lights, etc.) for use by ray tracer204 and shader 206. Of particular relevance to the present invention, asfurther shown in FIG. 2, scene server 202 can maintain object visibilityrelationships and rules 210.

[0018] It should be apparent that many other components, stores andgraphics data and instructions can be included or processed in therendering system 104, but these will not be illustrated or described soas not to obscure the invention. Moreover, it should be noted that sceneserver 202, ray server 203, ray tracer 204 and shader 206 are shown anddescribed separately for clarity of the invention. However, it should beapparent that these components and the functionality performed by eachas described herein can be consolidated and/or divided among fewer oradditional components, including scene server 202, ray server 203, raytracer 204 and shader 206. In one example implementation, ray tracer 204and shader 206 are implemented together as multiple ASICs in adistributed computing architecture in which scene server 202 and rayserver 203, implemented as software executing on one or more processors,act as hosts to divide a scene into multiple partitions and providegraphics data and instructions to individual ray tracer and shader ASICsrespectively assigned to the partitions. However, it should be apparentthat many alternative implementations and topologies are possible.

[0019] Generally, in operation, scene server 202 extracts object datafrom the graphics input, updates and/or maintains the appropriategraphics data in store 208, and provides image resolution parameters andcamera information to ray server 203. In one example implementation, fora given scene or frame to be rendered, scene server 202 determines thecenter of projection and window on the view plane (i.e. the camera oreye view) of the scene and provides this information to ray server 203.Ray server 203 then causes ray tracer 204 and shader 206 (orrespectively assigned circuits thereof) to compute the color of eachpixel in the window. For example, for a given pixel (or for eachsubpixel in a pixel), ray server 203 determines the camera ray from thecenter of projection through the pixel, and instructs ray tracer 204 todetermine objects hit by the ray. For certain implementations, raytracer 204 may further generate rays that are spawned from the originalray (e.g. reflections, refractions and shadows). Given the objects hitby or shadowed from the original and subsidiary rays, as computed by raytracer 204, shader 206 computes the color contributed by each object forthat pixel, and may further generate additional rays to be processed.Those skilled in the art will understand how to implement or adapt ashader 206 that computes colors given the output of a ray tracer andother shading information, and so an even further detailed descriptionthereof is unnecessary for an understanding of the present invention.

[0020] In accordance with an aspect of the invention, scene server 202further extracts object visibility relationships and rules from thegraphics input and maintains lists associated therewith in store 208.Ray tracer 204 can thus consider these relationships and rules whenperforming ray tracing processing, as will be described in more detailbelow.

[0021]FIGS. 3A to 3C are directed to an example scene containing objectsfor rendering that illustrates certain aspects of the present invention.

[0022] As shown in FIG. 3A, a scene includes objects 302, 304, 306, and308, and light L1 that potentially illuminates objects 302 and 304. Inone example, a camera ray is projected into the scene and strikes object302 at point P1 on a surface (a front facing surface in this example) atwhich there is a normal N1. Using recursive ray tracing techniques, atpoint P1, refracted ray T1 and reflected ray R1 are spawned. Refractedray T1 continues through object 302 and strikes the back surface atpoint P2, at which point reflected ray R2 and refracted ray T2 arespawned. Reflected ray R1 strikes the surface of object 304 at point P3having a normal N2 thereat. At point P3, reflected ray R3 is spawned.

[0023] As further shown in FIG. 3A, ray tracing processing will includedetermining any shadows at points P1, P2 and P3. Therefore, if light L1is associated with objects 302 and 304, shadow rays S1 and S2 will beprojected from points P1 and P3, respectively, toward L1 to determinethe visibilities associated with each due to the presence of occludingobjects. In this example, object 306 lies in the path of both S1 and S2,and so rays S1 and S2 would intersect object 306 at points P4 and P5,respectively. The complete ray tree for the above-described ray tracingis shown in FIG. 3B.

[0024] As discussed above, an aspect of the present invention includesthe ability to control the visibility of certain objects and how certainobjects and/or lights can affect the appearance of other objects and/orlights. As is clear from the example in FIG. 3A, the appearance ofobject 302 (at least at point P1) is affected by both objects 304 and306. Suppose, however, that a content creator wished to create a specialrelationship between objects 304 and 306 such that no shadows will becast on object 304 from object 306, for example. The creator would thenspecify a rule (using plug-in application 103 in modeling system 102,for example) that no shadow rays from object 304 striking object 306 areallowed (i.e., no shadows from object 306 should be cast on object 304).Rendering system 104, after considering the rule established by thecontent creator and included in the graphics input from the modelingsystem 102, would then disallow ray-object intersection processingbetween shadow ray S2 and object 306. As shown in FIG. 3A, shadow ray S2projects on toward L1, and strikes object 308 at point P6. The ray treeafter such rule processing is shown in FIG. 3C. When shading object 302at point P1 due to the camera ray, therefore, the shader will arrive atthe appropriate color by traversing the ray tree shown in FIG. 3C, whichdoes not include the intersection of shadow ray S2 with object 306,rather than the original ray tree shown in FIG. 3B.

[0025] The present invention contemplates many types and combinations ofobject visibility rules that can be specified. For example, a designercan specify that an object should not be affected by reflected,refracted or shadow rays that intersect certain other objects or photonrays from certain light sources. Or, a designer can specify that anobject should not be affected by reflected, refracted or shadow raysthat intersect any other objects or photon rays that originate from anylights except for a designated set. Such rules can be generallyspecified in a format such as “<OBJID> exclude/include <RAYTYPE><OBJLIST>,” which indicates that when processing rays for the objectspecified by OBJID, exclude/include rays of RAYTYPE (e.g. reflected,refracted, shadow, camera, photon) that intersect the list of objectsand/or lights specified by OBJLIST. Where a content creator wishes toexclude the effects of only a limited number of objects and/or lights onthe display of other objects and/or lights, the “exclude” rule may bemore efficient. Conversely, where the effects of all but a limitednumber of objects and/or lights are intended to be excluded, the use ofthe “include” rule may be more efficient. It will become apparent tothose skilled in the art, after being taught by the present disclosure,that there are many variations in how object visibility rules may bespecified, stored or processed to achieve substantially the same objectvisibility results in substantially the same way, and so the inventionis not limited to the above described rule formats but rather embracesalternative embodiments exploiting such variations.

[0026] In one implementation, the object visibility rules are specifiedin a modeling system adapted in accordance with the invention. This canbe done, for example, by including a plug-in application(s) 103 to anAPI included in the modeling system environment, which plug-inapplication allows the content creator to specify these rules inaddition to performing other object modeling tasks. Along with othergraphics data and instructions, the rules can be provided in an adaptedRIB or other graphics stream to the rendering system 204. The renderingsystem can then extract these rules from the bytestream for processingin accordance with the present invention. It should be noted, however,that there can be other ways to specify and receive the objectvisibility rules in addition to, or in place of, a modeling system, andso the present invention is not limited thereby.

[0027] When processing the RIB or other graphics input from the modelingsystem, the rendering system can create and/or populate data structuressuch as those illustrated in FIG. 4 for internal use by other componentsof the rendering system. As can be seen in this example, thesestructures are a linked set of lists. Particularly, object descriptor402 includes pointers to lists of objects for various forward andbackward ray types such as reflected rays 404, refracted rays 406,shadow rays 408 and photon rays 410. Along with the pointer there may bestored an indication of the number of objects stored in the respectivelist 404, 406, 408, 410. Accordingly, when a ray tracer such as raytracer 204 is processing rays from a point of intersection on an objector from a light source, it will consult object descriptor 402. Thus,when a reflected ray is spawned from the point of intersection on anobject, for example, the ray tracer will determine whether any objectsare stored in reflections list 404 for the intersected object (e.g. ifthe number/length of the list is nonzero as specified in objectdescriptor 402), and if so, it will ignore any intersections of thespawned reflected ray with objects listed in list 404 (or ignoreintersections for all but the listed objects if list 404 specifies an“include” rule).

[0028] It should be apparent that the types of rays that can be includedfor special processing in accordance with the invention is not limitedin number or type to the specific types of rays listed above, but mayinclude fewer or additional types of rays, whether specificallymentioned in the list of ray types provided herein or not. It should befurther apparent that additional object information may be stored andconsidered for object rendering beyond that illustrated in FIG. 4, andthat object descriptor 402 may be included in, or separate from, suchfurther information.

[0029] An example method for controlling the appearance of objectsrendered in a scene that can be executed by a graphics system inaccordance with an aspect of the present invention is illustrated by theflowchart in FIG. 5.

[0030] As shown in FIG. 5, the rules received from the modeling systemare parsed and are used to populate the include/exclude lists such asthose illustrated in FIG. 4 (S502). For each ray of a scene or frame tobe rendered (determined in step S504), therefore, the list of objectvisibility rules for the object or light source from which the ray isprojecting is retrieved (S506). Regardless of the type of ray that isbeing projected from the point of intersection with the object (e.g.reflected, refracted, shadow, etc.), the ray tracer begins to trace theray from a point of intersection or light source (S508). The nearestobject struck by the ray is then compared to the list of rules specifiedfor the originating object or light source and the ray type (S510). Ifthe struck object is specified in the list, and is associated with an“include” rule, or if the object is not specified in the list, normalray-object intersection processing with the object will be performed(S512). This may include, for example, determining a point ofintersection on the object, and spawning other rays from the point ofintersection. Otherwise, the object is specified in the list and isassociated with an “exclude” rule. Accordingly, it should be excludedfrom ray-object intersection processing and is skipped (see “Exclude”arrow back to step S508). Finally, it is determined whether anyadditional tracing for this ray should be performed (S514). If so,processing returns to step S508. Otherwise, processing returns to stepS504.

[0031] Although not shown, it should be understood that when a ray treeis completed or as it is generated, it can be provided to a shader suchas shader 206 for determining the color associated with the originalray-object intersection corresponding to the ray tree. For example, ifthe ray tree is constructed for a camera or eye ray associated with apixel, the shader will compute the color for the pixel by traversing theray tree as constructed by the ray tracer in accordance with a methodsuch as that described above. It should be further understood that theprocessing of the ray tree need not sequentially follow completion ofthe construction of the ray tree, but that certain shading operationsmay be performed in parallel with certain ray tracing operations.Moreover, it should be apparent that the shader may process certain rays(e.g. shadow rays) separately from ray trees. Those skilled in the artwill understand the various implementation alternatives and the presentinvention embraces corresponding alternative embodiments. Furthermore,it should be understood that additional rendering and ray tracingoperations may be performed in conjunction with or in addition to theabove-described processing, such as computing intersection points anddetermining opacities and the like.

[0032] It should be further noted that the above described method doesnot include detailed descriptions of other ray tracing, rendering andshading operations that may be performed in conjunction with or inaddition to the processing described above. Details of such otheroperations are omitted here so as not to obscure the invention.Moreover, the invention is not limited to any specific sequence orimplementation of such additional operations.

[0033] Although the present invention has been particularly describedwith reference to the preferred embodiments thereof, it should bereadily apparent to those of ordinary skill in the art that changes andmodifications in the form and details may be made without departing fromthe spirit and scope of the invention. It is intended that the appendedclaims include such changes and modifications.

What is claimed is:
 1. A graphics apparatus, comprising: a renderingsystem that renders an object in response to a graphics input, thegraphics input including object visibility rules, the rendering systemconstraining the rendering of the object in accordance with the objectvisibility rules.
 2. A graphics apparatus according to claim 1, whereinthe rendering system receives the graphics input from a modeling system.3. A graphics apparatus according to claim 1, wherein the renderingsystem includes a ray tracer, the object visibility rules specifying arelationship between the object and certain rays, the ray tracer lookingup a rule associated with the object when processing the certain raysfor the object.
 4. A graphics apparatus according to claim 1, whereinthe rendering system includes a ray tracer, the object visibility rulesspecifying a relationship between the object and certain other objectsfor certain rays, the ray tracer looking up a rule associated with theobject when processing the certain rays for the object.
 5. A graphicsapparatus according to claim 3, wherein the certain rays include raysoriginating from a point of intersection with the object.
 6. A graphicsapparatus according to claim 1, wherein the rendering system includes aray tracer, the object visibility rules specifying a relationshipbetween light sources and certain rays, the ray tracer looking up a ruleassociated with one of the light sources when processing the certainrays for the light source.
 7. A graphics apparatus according to claim 6,wherein the certain rays include rays originating from the light sourceand potentially intersecting the object.
 8. A graphics apparatusaccording to claim 3, wherein the ray tracer constructs a ray treeassociated with the object in accordance with the object visibilityrules.
 9. A graphics apparatus according to claim 3, wherein therelationship establishes objects to be excluded from processing for thecertain rays.
 10. A graphics apparatus according to claim 3, wherein therelationship establishes objects to be included for processing for thecertain rays to the exclusion of all other objects.
 11. A graphicsapparatus according to claim 1, further comprising a modeling systemadapted to construct the object visibility rules in accordance with userinputs.
 12. A plug-in application for a modeling system that constructsobject visibility rules in response to user input, the object visibilityrules being supplied to a rendering system in a graphics input from themodeling system, the rendering system rendering an object in response tothe graphics input, the rendering system constraining the rendering ofthe object in accordance with the object visibility rules.
 13. A plug-inapplication according to claim 12, wherein the rendering system includesa ray tracer, the object visibility rules specifying a relationshipbetween the object and certain rays, the ray tracer looking up a ruleassociated with the object when processing the certain rays for theobject.
 14. A plug-in application according to claim 13, wherein thecertain rays include rays originating from a point of intersection withthe object.
 15. A plug-in application according to claim 12, wherein therendering system includes a ray tracer, the object visibility rulesspecifying a relationship between light sources and certain rays, theray tracer looking up a rule associated with one of the light sourceswhen processing the certain rays for the light source.
 16. A plug-inapplication according to claim 15, wherein the certain rays include raysoriginating from the light source and potentially intersecting theobject.
 17. A plug-in application according to claim 12, wherein the raytracer constructs a ray tree associated with the object in accordancewith the object visibility rules.
 18. A plug-in application according toclaim 12, wherein the relationship establishes objects to be excludedfrom processing for the certain rays.
 19. A plug-in applicationaccording to claim 12, wherein the relationship establishes objects tobe included for processing for the certain rays to the exclusion of allother objects.
 20. A graphics apparatus comprising: a scene server thatreceives a graphics input specifying a plurality of objects and extractsobject visibility information from the graphics input; and a ray tracercoupled to the scene server that determines intersections of rays withcertain of the plurality of objects included in a scene, the ray tracerreceiving the object visibility information and constraining the rayintersection determination in accordance therewith.
 21. A graphicsapparatus according to claim 20, wherein the object visibility rulesspecify relationships between the objects and certain types of the rays,the ray tracer constraining the ray intersection determination for thecertain types of rays in accordance with the specified relationships.22. A graphics apparatus according to claim 21, wherein the certaintypes of the rays include one or more of shadow rays, refracted rays,reflected rays and photon rays.
 23. A graphics apparatus according toclaim 20, wherein the ray tracer constructs ray trees associated withthe certain objects and the intersections, the ray tracer constrainingobjects to be included in the ray trees in accordance with the objectvisibility rules.
 24. A graphics apparatus according to claim 21,wherein the relationships establish objects to be excluded fromprocessing for the certain types of rays.
 25. A graphics apparatusaccording to claim 21, wherein the relationships establish objects to beincluded for processing for the certain types of rays to the exclusionof all other objects.
 26. A graphics apparatus according to claim 20,further comprising a shader coupled to the ray tracer for determiningcolors associated with the intersections.
 27. A graphics apparatusaccording to claim 23, further comprising a shader coupled to the raytracer for determining colors associated with the ray trees.
 28. Agraphics apparatus according to claim 20, wherein the scene serverreceives the graphics input from a modeling system.
 29. A graphicsapparatus according to claim 20, further comprising a modeling systemadapted to construct the object visibility rules in accordance with userinputs.
 30. A graphics apparatus according to claim 20, furthercomprising a plug-in application that constructs the object visibilityrules in accordance with user inputs.
 31. A graphics apparatuscomprising: means for receiving a graphics input specifying a pluralityof objects; means for extracting object visibility information from thegraphics input; and means for determining intersections of rays withcertain of the plurality of objects in a scene, the determining meansincluding means for receiving the object visibility information andmeans for constraining the ray intersection determination in accordancetherewith.
 32. A graphics apparatus according to claim 31, wherein theobject visibility rules specify relationships between the objects andcertain types of the rays, the determining means determining theintersections for the certain types of rays in accordance with thespecified relationships.
 33. A graphics apparatus according to claim 32,wherein the certain types of rays include one or more of shadow rays,refracted rays, reflected rays and photon rays.
 34. A graphics apparatusaccording to claim 31, wherein the determining means further includesmeans for constructing ray trees associated with the certain objects andthe intersections, the constraining means constraining objects includedin the ray trees in accordance with the object visibility rules.
 35. Agraphics apparatus according to claim 32, wherein the relationshipsestablish objects to be excluded from processing for the certain typesof rays.
 36. A graphics apparatus according to claim 32, wherein therelationships establish objects to be included for processing for thecertain types of rays to the exclusion of all other objects.
 37. Agraphics apparatus according to claim 31, further comprising means fordetermining colors associated with the intersections.
 38. A graphicsapparatus according to claim 34, further comprising means fordetermining colors associated with the ray trees.
 39. A graphicsapparatus according to claim 31, wherein the receiving means receivesthe graphics input from a modeling system.
 40. A graphics apparatusaccording to claim 31, further comprising means for constructing theobject visibility rules in accordance with user inputs.
 41. A graphicsmethod comprising: receiving a graphics input specifying a plurality ofobjects; extracting object visibility information from the graphicsinput; and determining intersections of rays with certain of theplurality of objects in a scene, the determining step includingreceiving the object visibility information and constraining the rayintersection determination in accordance therewith.
 42. A graphicsmethod according to claim 41, wherein the object visibility rulesspecify relationships between the objects and certain types of the rays,the determining step including determining the intersections for thecertain types of rays in accordance with the specified relationships.43. A graphics method according to claim 42, wherein the certain typesof rays include one or more of shadow rays, refracted rays, reflectedrays and photon rays.
 44. A graphics method according to claim 41,wherein the determining step further includes constructing ray treesassociated with the certain objects and the intersections, theconstraining step including constraining objects included in the raytrees in accordance with the object visibility rules.
 45. A graphicsmethod according to claim 42, wherein the relationships establishobjects to be excluded from processing for the certain types of rays.46. A graphics method according to claim 42, wherein the relationshipsestablish objects to be included for processing for the certain types ofrays to the exclusion of all other objects.
 47. A graphics methodaccording to claim 41, further comprising determining colors associatedwith the intersections.
 48. A graphics apparatus according to claim 44,further comprising determining colors associated with the ray trees. 49.A graphics apparatus according to claim 41, wherein the receiving stepincludes receiving the graphics input from a modeling system.
 50. Agraphics apparatus according to claim 41, further comprisingconstructing the object visibility rules in accordance with user inputs.